home *** CD-ROM | disk | FTP | other *** search
/ TEKNO 1996 February / TEKNO 2-1996.iso / quake / video.txt < prev   
Text File  |  1996-02-24  |  12KB  |  340 lines
  1. +----------------------------------------+
  2. | The Official Quake Deathmatch TEST     |
  3. | Released Saturday, February 24th, 1996 |
  4. | Copyright (C) 1996 id Software, inc.   |
  5. +----------------------------------------+
  6. | Video Subsystem Documentation          |
  7. | by Michael Abrash                      |
  8. +----------------------------------------+
  9.  
  10. Quick start
  11. -----------
  12.  
  13. To see the video modes available, bring up the console (either
  14. start Quake without loading a level, or press Esc while in a level).
  15. Type vid_describemodes<enter> to see all available modes.  Type
  16. vid_mode <mode #> to set a mode, where <mode #> is the mode number
  17. listed for the desired mode by vid_describemodes.
  18.  
  19. See "Bug Reporting," below, for information on how to report any
  20. problems you encounter.
  21.  
  22.  
  23. More detail
  24. -----------
  25.  
  26. This version of Quake supports software drawing in a variety of
  27. video modes.  It does not support any hardware accelerators.  Video
  28. modes that are always supported are:
  29.  
  30. 320x200, 360x200, 320x240, 360x240, 320x350, 360x350, 320x400,
  31. 360x400, 320x480, 360x480
  32.  
  33. In addition, all VESA 2.0 256-color linear framebuffer modes
  34. supported by the video adapter are supported.  Further information
  35. about VESA 2.0 is provided below.
  36.  
  37.  
  38. Video mode reporting and selection
  39. ----------------------------------
  40.  
  41. Quake assigns each available video mode a mode number, which can
  42. then be used to query information about the mode or to select the
  43. mode.  The first 11 mode numbers are always as follows:
  44.  
  45. 0:  320x200
  46. 1:  320x200
  47. 2:  360x200
  48. 3:  320x240
  49. 4:  360x240
  50. 5:  320x350
  51. 6:  360x350
  52. 7:  320x400
  53. 8:  360x400
  54. 9:  320x480
  55. 10: 360x480
  56.  
  57. You will notice that modes 0 and 1 are both 320x200; mode 1 is a
  58. Mode X-style version, which will someday allow support of page
  59. flipping for cleaner graphics, but right now it's just slower with
  60. no advantages, so use mode 0 for 320x200 resolution.  Modes 2-10
  61. are all higher resolution than mode 0, and look very nice, but are
  62. also all slower than mode 0.  Mode 0 is the fastest of the 11
  63. built-in modes.
  64.  
  65. In addition to the built-in modes, Quake checks for the presence
  66. of a VESA version 2.0 driver.  If such a driver is detected, the
  67. driver is queried for all 8-bit-per-pixel linear framebuffer (LFB)
  68. modes that are supported.  All such modes are added to the mode
  69. list starting at mode 11.  The available modes will vary depending
  70. on adapter, graphics chipset, amount of memory, and VESA 2.0 driver.
  71. The higher the resolution, the lower the performance, and the
  72. higher-resolution modes will often be too slow for good gameplay
  73. on most machines.  The screen can be sized down to improve performance
  74. in higher-resolution modes, but then of course the effective
  75. resolution of Quake is reduced.
  76.  
  77. In its current form, Quake supports only page-flipped VESA modes.
  78. This means that on adapters, such as the Diamond Viper, that don't
  79. support VESA-compatible page-flipping, Quake will not report any
  80. available VESA modes.  Modes 0-10 will still be supported on those
  81. adapters, however.  Similarly, modes that use more than half the
  82. total video memory for the screen, and thus can't provide two pages
  83. for page-flipping, are not available under Quake.  Thus, on a 1 Mb
  84. adapter, a 1024x768 mode, which uses 0.75 Mb, will not be reported
  85. as available.
  86.  
  87. Quake always starts up in mode 0, and modes 0-10 are always available.
  88.  
  89.  
  90. How to get VESA 2.0 support
  91. ---------------------------
  92.  
  93. Some video adapters have VESA 2.0 support in ROM.  Other video
  94. adapters come with loadable VESA 2.0 TSRs.  In the absence of either
  95. of these, UniVBE, from SciTech, provides VESA 2.0 support for most
  96. video adapters.  The latest version of UniVBE can be obtained from
  97. the following locations:
  98.  
  99. www: http://www.scitechsoft.com
  100. ftp: ftp.scitechsoft.com
  101. Compuserve: GO VESA
  102. AOL: Keyword VESA
  103.  
  104. SciTech can be contacted at:
  105.  
  106. email: sales@scitechsoft.com
  107.  
  108. SciTech Software
  109. 5 Governors Lane, Suite D
  110. Chico, CA
  111. 95926-1989
  112.  
  113. The currently most recent version is UniVBE 5.1a.  UniVBE 5.2,
  114. which should be released soon, will support more adapters and add
  115. many low- and medium-resolution modes, such as 512x384.
  116.  
  117.  
  118. Video-related commands
  119. ----------------------
  120.  
  121. vid_describecurrentmode: lists the description for the current
  122. video mode.
  123.  
  124. vid_describemode <mode #>: lists the description for the specified
  125. video mode, where <mode #> is as reported by vid_describemodes.
  126.  
  127. vid_describemodes: lists descriptions for all available video modes.
  128.  
  129. vid_mode <mode #>: sets the display to the specified mode, where
  130. <mode #> is as reported by vid_describemodes.
  131.  
  132. vid_nummodes: reports the total number of modes available.
  133.  
  134. vid_testmode <mode #>:  tries to switch Quake to the specified
  135. mode, then returns to the current mode after 5 seconds.  This allows
  136. you to try an untested mode without ending up with a black screen
  137. if, for example, the monitor can't display the mode properly.
  138. There may still be instances in which, due to VESA driver or hardware
  139. bugs, the machine will hang in certain modes; vid_testmode can't
  140. recover from these situations, but it can recover from a blank or
  141. scrambled screen.
  142.  
  143. vid_wait <wait type>: sets the type of waiting that the video
  144. adapter should do, as follows:
  145.  
  146. 0: no waiting
  147. 1: wait for vertical sync active
  148. 2: wait for display enable active
  149.  
  150. The default state of vid_wait depends on the video mode selected.
  151. In built-in modes 0-10, the default is always 0, no waiting.  You
  152. can set vid_wait to 1 (wait for vertical sync) to eliminate shear
  153. and tearing in these modes (so partially-completed frames are never
  154. drawn, resulting in a rock-solid image).  However, waiting for
  155. vertical sync can result in substantial performance loss.
  156.  
  157. In VESA modes, if the adapter is VGA compatible and there's enough
  158. memory for three video pages, then triple-buffering is enabled and
  159. vid_wait is set to 2, wait for display enable.  There is little
  160. performance loss to this sort of waiting.  If the adapter is not
  161. VGA compatible, or if there's only enough memory for double-buffering,
  162. then vid_wait is set to 1 (wait for vertical sync).  This can cause
  163. significant loss of performance, but some sort of wait is generally
  164. necessary to avoid occasional glitching of the screen when
  165. page-flipping; we always choose the lowest-cost wait option that
  166. we're sure is safe to use.
  167.  
  168. The default setting for vid_wait can be changed from the console
  169. at any time.  If you are in a VESA mode that waits for vertical
  170. sync and want to turn it off to get a speed-up, you can do so.
  171. However, changing a vid_wait 1 default in a VESA mode may result
  172. in problems.  If vid_wait defaults to 1 (wait for vertical sync)
  173. in a mode, and you force it to 2 (wait for display enable), the
  174. machine may hang, because some VGA-incompatible adapters, such as
  175. some ATI Mach64s, don't support the display enable status.  If you
  176. force vid_wait to 0 (no wait), then the screen may glitch periodically
  177. if the page flips at a time that results in a bad flip address,
  178. although some adapters work fine with no wait at all.
  179.  
  180. If you force a new setting for vid_wait and encounter problems, DO
  181. NOT send us a bug report!
  182.  
  183.  
  184. Setting the video mode automatically
  185. ------------------------------------
  186.  
  187. If you want to default to a mode other than mode 0, place the line:
  188.  
  189. vid_mode <mode #>
  190.  
  191. in your .cfg file; the mode will be selected when you exec the .cfg
  192. file, either from the console or with +exec <filename>.cfg on the
  193. command line when you start Quake.  Note that if you use the .cfg
  194. file on another machine, it may cause problems if the other machine
  195. doesn't support the specified mode; the mode set should merely
  196. fail, but bugs in the VESA driver or the hardware can possibly
  197. cause the machine to hang.  You can always get the machine to
  198. function properly by removing the vid_mode line from the .cfg file,
  199. or not execing the .cfg file.
  200.  
  201.  
  202. Known video problems and workarounds
  203. ------------------------------------
  204.  
  205. There are currently no known video bugs in Quake, which of course
  206. doesn't mean there are no video bugs.  If you think you've encountered
  207. a bug, see "Bug Reporting," below.  As a general rule, go back to
  208. mode 0 if you have problems; mode 0 should work properly in all
  209. cases.
  210.  
  211. On some ATI Mach64 adapters, the palette is sometimes too dark in
  212. 320x200 and 320x240 VESA modes.  The workaround is to use different
  213. modes, such as 360x200, 360x240, or mode 0.
  214.  
  215. In modes 0-10, shear and tearing can occur as partially finished
  216. frames are displayed.  Workaround:  set vid_wait to 1 (wait for
  217. vertical sync); this can result in a substantial performance loss,
  218. however.  An alternative is to use a VESA mode.
  219.  
  220. In VESA modes, occasional glitched frames may occur with some VESA
  221. driver-hardware combinations.  Workaround:  set vid_wait to 1 (wait
  222. for vertical sync), or use a different mode.
  223.  
  224. A very fast machine displaying simple scenes could possibly run
  225. faster than the video frame rate, resulting in flicker.  Workaround:
  226. set vid_wait to 1 (wait for vertical sync).  An alternative is to
  227. use a higher-resolution mode.
  228.  
  229.  
  230. Performance
  231. -----------
  232.  
  233. Quake's graphics are not yet fully optimized, but should be adequately
  234. fast on all Pentium-class machines.  486-based machines will be
  235. sluggish.  You will see a turtle icon appear in the upper left
  236. corner of the screen if the frame rate drops below 10 frame/second;
  237. if you are getting the turtle, you are probably not getting great
  238. gameplay.  Performance can be improved in several ways:
  239.  
  240. * size down the screen with the minus key
  241.  
  242. * select a lower-resolution mode, if possible
  243.  
  244. * use a VESA mode
  245.  
  246. * if you're using a VESA mode and vid_wait is set to 1 (wait for
  247. vertical sync) by default (you can check by typing vid_wait<enter>
  248. in the console), you can try setting vid_wait to 0 or 2, as detailed
  249. in the discussion of the vid_wait command above.  Be aware that
  250. risks of screen glitching or hung machines are associated with
  251. overriding a default vid_wait 1 setting in VESA modes.
  252.  
  253.  
  254. Bug Reporting
  255. -------------
  256.  
  257. If you encounter a video-related bug, please fill out the following
  258. form and e-mail it to qtest1@idsoftware.com.  There are several
  259. problems that are not bugs, and shouldn't be reported, including:
  260.  
  261. * unavailability of some VESA modes; as noted above, VESA modes
  262. are only supported by Quake if they have enough memory and the
  263. hardware capability to support VESA-style page-flipping
  264.  
  265. * problems that occur when you change vid_wait from a default value
  266. of 1 (wait for vertical sync) in VESA modes
  267.  
  268. * sluggish performance, especially on 486s
  269.  
  270. * the known palette problem in 320x200 and 320x240 VESA modes on
  271. some Mach64s.
  272.  
  273. Apart from these, we would very much like to hear about any video
  274. problems you encounter.
  275.  
  276.  
  277. -------------------------------cut here-------------------------------------
  278.  
  279.             Quake Deathmatch TEST #1 Bug Report
  280.  
  281.  
  282. E-mail to: qtest1@idsoftware.com
  283.  
  284.  
  285. Date:
  286.  
  287.  
  288. Name:
  289.  
  290. Company:
  291.  
  292. Street address:
  293.  
  294. City, state, ZIP:
  295.  
  296. Phone:
  297.  
  298. Fax:
  299.  
  300. E-mail:
  301.  
  302.  
  303.  
  304. Manufacturer/model of graphics adapter (company, model, chipset if
  305. known; if you are using UniVBE, please run uvconfig and list the
  306. chipset, RAMDAC, and clock chipinformation that's reported):
  307.  
  308.  
  309.  
  310.  
  311.  
  312. Is the problem associated with a VESA mode?
  313.  
  314.  
  315.  
  316. If so, what is the VESA driver and version?  (eg., UniVBE 5.1a,
  317. built into board BIOS, or manufacturer provided TSR)
  318.  
  319.  
  320.  
  321. What operating system are you running?  (eg., DOS 6.0 or Windows
  322. 95):
  323.  
  324.  
  325.  
  326.  
  327. Please describe the problem you are encountering, including a
  328. procedure for reproducing the problem:
  329.  
  330.  
  331.  
  332.  
  333. Please list any error messages, crash dump, or other information
  334. that you think might be relevant:
  335.  
  336.  
  337.  
  338.  
  339. -------------------------------cut here-------------------------------------
  340.